This invention relates to a method and system for ranking services in a web services architecture. In particular, the invention relates to a web services architecture with an hierarchy of service providers in which the ranking is specified by the top level invoker.
Web services are described in the document “Web Services Conceptual Architecture (WSCA 1.0)” by IBM Software Group, May 2001. Web services provides a program-to-program communications model built on existing and emerging standards such as HTTP (hypertext transfer protocol), Extensible Markup Language (XML), Simple Object Access Protocol (SOAP), Web Services Description Language (WSDL) and Universal Description, Discovery and Integration (UDDI).
A web service is described through an interface that describes a collection of functions that are network-accessible through standardized XML messaging. A web service is described using a standard, formal XML notation, called a service description. The service description covers all the details necessary to interact with the service, including message formats, transport protocols and location. The interface hides the implementation details of the service allowing it to be used independently of the hardware or software platform on which it is implemented and also independently of the programming language in which it is written. It is also independent of the hardware and software environment of the caller. This allows web services-based applications to be loosely coupled, component-oriented, cross-technology implementations that can be published, located, and invoked across a network.
Web services are implemented in a network. The network could be a publicly-accessible network such as the Internet, an Intranet or any other form of network. Internet-available web services use commonly deployed network protocols. Such protocols may be HTTP or other Internet protocols such as SMTP or FTP. Other networks (e.g. Intranets) can use reliable messaging call infrastructures such as MQSeries, COBRA, etc.
The described method and system relate to an extension of the UDDI/WSDL protocol and XML/SOAP syntax to provide functions that are not currently available within the web services architecture.
Reference is made to the following documents available via www.uddi.org:
UDDI 2.0 Data Structure Reference;
UDDI 2.0 API Specification;
UDDI 2.0 Operators Specification; and
Web Services Description Language (WSDL) 1.1.
The aim of UDDI in web services is to provide open access to functions based on a directory or registry lookup. These services are described by the WSDL part and invoked by the XML/SOAP function. The binding of the invoker to the service is dynamic and not fixed. It is open in that the directory is freely available and there are no constraints applied to how the lookup or selection occurs. UDDI admirably meets this objective. However, where it fails is in concepts like quality of service.
The described method and system provide means whereby quality of service issues and other selection influencing factors can be introduced into the UDDI/WSDL arena.
In web services, a directory or registry is used to assemble software in a componentized fashion. The idea of UDDI is that a WSDL-formatted request is sent to a directory or registry server to select a service. This service selection can be specified on certain generally applicable criteria such as the company that is providing it and the function it does. This selection information is very generic; it is the same for all users and there is nothing specific to the originator of the request for the service that is mentioned.
The described method and system provide means whereby specific-to-originator criteria can be bought to bear on the lookup. Unlike in known prior art web services, the selection of the service is influenced by an originator or requester of the service selection.
The following is a practical example. A user's software is going to buy a book. The user looks up in a directory under the category of ‘Book Sellers’ and gets back a list of companies offering that service. However, the user has negotiated preferential rates with, say two, suppliers, and so wants to send the purchase request to either of these two in the first instance, and someone else as a third choice.
The user can do this by filtering the returned list of companies from the search because the search returned information to the user directly and the user is in control of what happens next.
A difference arises if the book purchase request is being done as part of the function of a service that is being provided by someone else. For example, the user may be building a library of StarTrek books. The user uses a ‘Build a library’ selection and gets back a list of suitable sellers. The user places his Get-me-a-library-for-StarTrek request to this supplier who will do the job. However, the user is now no longer in the position to use his favorite list of Book Sellers as the book-buying function is now being handled by someone else. In effect, they use their preferred suppliers instead of the users.